Pshaw, and they say it only ever rains in Portland.

Yay. A Meme. And I have a bad enough headache to write something… My own machine set uses something from the Babylon5 series, so I have delenn (laptop), vorlon (desktop) (Yes, contrary to common believe it is not named after that prior Release Manager of Debian :)), sheridan/vir/kosh/lyta/morden (various servers). More interesting is the naming scheme i took for DebConf hosts: Characters from the Simpsons, but the names have to make some kind of sense with the function of the machine. And names from members of the Simpsons family are forbidden and to be used for machines directly at a DebConf venue only. Some of the names we use are cmburns, smithers, apu, skinner, quimby, wiggum, herb, krabappel, horatio, cletus, kent, krusty. Look for the TXT records to know who it is, all of them have one. Finding out why the hosts carry those names is left as an excercise to the reader, except for two to demonstrate the twisted brain you need to get it :)

• krusty - Krusty the Clown. Was the master video relay for DC8 (and will be for some others) and as such presenting/managing/getting a/the show to the people watching from outside.
• horatio - The Sea Captain. Is used as the shell machine for DebConf people that do not have an own shell box, but which we want to have in IRC for basically 24/7. So shell <-> sea.

At work it is extremely boring, descriptive names for the function. Like mail1, mail2, etc.

---

Oh, and also, lets shoot madduck. Comments: 1

Like Jaldhar, I too am thrilled at the news that McCain has chosen Palin as his running mate. Finally, a candidate who embodies the truly American spirit of the Republican party! Haven't we had enough political circus in Washington? Isn't it time to give Flying Circus a chance?

I'm back (for several days now) from Argentina and DebConf 8 to Portland. Too long a journey and too short a trip, as always. It was great to see everybody again as well as to meet a number of new folks from the local community. Here's hoping that DebConf 8 inspires more involvement in Debian from Argentina! It was my first time to this wonderful South American country, which made it even more melancholy to have to leave after such a short time and to be making this trip without Patty. Random observations about Argentina, for posterity:

• The 6-hour bus ride from Buenos Aires to Mar del Plata looks an awful lot like Iowa. Except for the occasional palm tree and the fact that it's 20 C in winter.
• Well, ok... Iowa also tends not to have quite so many cows. Or country grills (parrillas) right next to pastures...
• All the towns along the route are named after generals or colonels?
• All the police on the highway wear OSHA green vests.
• Following the German with the voluminous guidebook is an effective way to acquire generous portions of bife de chorizo.
• People from Bah a Blanca seem to have a somewhat more paranoid opinion of what constitutes a "dangerous neighborhood" than I do. :)
• "Buenos Aires" appears, I'm sad to say, to be a marketing lie. There was nothing bueno about the aire on the autopista on the ride to the airport. But the air in Mar del Plata was quite nice, and the people were the best!

As always it was a pleasure to take part in another annual DebConf, an event which is such a positive force for rejuvenating the Debian community. And BTW, Biella, NYC is not the only US city entertaining a bid for DebConf 10.

Here I am writing today to tell something that might not be known outside Brazil at least, I haven t read much in English about it the attempt to turn the Internet into a government surveillance device. This story goes back to 2006 (and even back), when we first successfully blocked the approval of a bill that would, in effect, turn the Brazilian Internet into a giant Big Brother. This bill was introduced by Senator Eduardo Azeredo as a replacement to a series of other similar bills that were attempted before and was followed by a strong resistance by civil organizations, one of those being ASL, of which I am proud of being one of the founders. By that time we ended having it postponed for more debate. It happened that the bill made a come back last weeks, and was pushed into approval by a subcommittee of the Senate (one that was suppose to deal with the constitutionality of bills) and now is heading to the Chamber of Deputies for appreciation. Apart from the first debates back in 2006, nothing happened between then and the approval. The bill have changed a little bit, but not much as to change its effects. In Brazil, we have two legislative houses, Federal Senate and Chamber of Deputies. If a Law Project is proposed by one, is revised by the other. So we have already lost 50% of the fight. Ronaldo Lemos, professor of Funda o Get lio Vargas (think about a Brazilian version of Harvard Law School ) have already stated how dangerous such a Law can be, once approved. In his own words: The wording of the law is too broad, and can be applied in several cases. The interpretation of what is a crime or not will be done by a criminal judge, who is used to deal with homicides and not with technology . Since its approval in Senate, several people have been putting together a resistance. Central to it is a Petition, hosted at Petition Online, that already holds 64-thousand signatures. One of the writers of that petition, Andr Lemos, a university professor and researcher, have said that the regular user will have the feeling of being watched, and not knowing if what he s doing in legal or not: For instance, if I disseminate a virus without knowing, will I be arrested? Can I exchange my files in P2P networks (my pictures, my musics, my text files) without asking for permission? How will the ISPs interpretate these exchanges? Can I copy a part of a text from a blog and paste it into mine? This law creates a feeling of insecurity and generalized fear . FGV s Center for Society and Technology have published an analysis of the Law Project, and have spotted a lot of problems in it. For instance:

• Unlock a cellphone to be used in another carrier or unlock a DVD player, so it reads disks from different regions, can be a crime punished with 1 to 3 years of imprisonment and a fine, as deals article 285-A;
• Copy something from a blog that doesn t state access restrictions is turned into a crime since a blog is covered by copyright and, if not stated otherwise, those restrictions should apply, and someone that copies can be punished with the same 1 to 3 years of inprisonment and a fine, as deals article 285-B;
• Unlock the iPhone using softwares like jailbreak is turned into a crime punished with 2 to 4 years of imprisonment and a fine, as deals article 163-A. Even put a link somewhere in your site pointing to the software jailbreak is considered a crime;
• The ISP is turned into a surveillance apparatus, and is mandate to inform the authorities about any of the crimes the Law deals with, as states article 22.

Thinking of how I can help, after sending an email to every Deputy whose email address I was able to get, I decided to translate the law into English (I also uploaded a version with indentation, since it s pretty hard to understand the whole law without it, if you re not used to), so the World can be made aware of what s going on in Brazil. I also just sent an email with it to EFF, asking for their help. Not that I think they can do much, but they surely will know one or two strings to pull in order to put more pressure on the Brazilian government. I also hope that, once this post reaches Planet Debian, even more people become aware of the issue. In a sense, this is an appeal for all the Freedom Culture lovers out there to take any actions they can to help us prevent this Law Project to become a Law. (In time, I d like to thank Alexandre Oliva, who revised the translation). Update (2008-07-23 11:50): Steve Langasek also revised the translation of the Law Project and I ve made a cherry-pick merge , which resulted in the version currently linked in the text above. Older version of the plain and the indented documents are still available. Thanks Steve!

Steve,

If you don't like seeing cumbersome security warnings for insecure https connections, how about not using https when what you really want is http in the first place?

Because I don't necessarily have the choice. When I'm reporting a bug on a given open source Trac, they often put https on them because they think it's better for them (and for them it is because they generated the certificate and so on), and there is no http version. Note that when I use https for myself, I import my CA in firefox, so I don't have a single warning, so I kind of know how to avoid them when I care about https. But there isn't always a plain HTTP alternative, and that is what makes it a real PITA. Okay, you want to warn the user the https isn't secure, there are plenty of ways that don't require you to add an exception on a certificate. I spoke of the little lock, because that's what is even on IE, but please remember than when you browse trusted https, the URL bar is in this kind of yellow. Well, if the https is unsecure, just don't put that background. If you really want, you can add some kind of rosa color to mark that it's "bad" but it in a not too terrible way (in opposition to a broken/invalid certificate and where the URL bar should be blinking red with an air-raid like siren). I repeat, the fact that the HTTPS certificate is self-signed never changes the fact that when a given user goes on this kind of https site, he wants to be there, and HE WILL click on the 5 silly steps of the SSL exception thing. So why bother ? It serve one single purpose: pissing users off. And for what it's worth, I disagree with you, most of the people that are not computer related I know absolutely don't know they could think that http_s_ is more secure than http. Each time I give them an URL without the http:// part they ask, is this https or http ?, because they absolutely don't get the difference, and I don't try to explain it to them, because this would lead them to think https is better. Those kind of people only rely on visual helpers from the browser part. They really do. PS: yes I also believe that bad security is worse than no security because it gives the illusion for people to be safe, and then they have bad behavior. When your condom is broken, things can go really wrong. But you missed my point, in the sense, probably because I'm too annoyed to make it clear inbetween rants. My point really was what I tried to explain, namely that if people don't know they should think there is security in the first place, your remark is moot, and for the other you can activate the different URL background, it's just fine. Of course, invalid certificates must remain a pain to go through, this whole thing is only about the untrusted ones.

Pierre, "Why on earth is https with an untrusted certificate less secure than http ?." Apparently you thought this was a rhetorical question. I disagree. https with an untrusted certificate is less secure than http, because whether or not most users understand the meaning of https, there are a significant number of users who do understand what it means, or at least think they do. You can't seriously tell me you that you think all users always look for the lock icon instead of looking at the URL to know whether they're protected, can you? Users, on the whole, are very good at cargo-culting where technology is concerned. Just because many users look for the icon does /not/ mean that there aren't other users who know just enough of the definition of "protocol" to be a danger to themselves. An https URL is a declaration on the part of the server (or the party linking to it) that the resource in question should be secure. This creates an expectation on the part of those users who know what https is that if the connection succeeds, it is secure, which means they'll think it's ok to do the kinds of things that they normally do over secure connections but won't do over unsecured ones. It therefore certainly is important to give users feedback that an https connection has failed. If you try to connect to an https resource, and your browser can't verify the certificate, something is wrong. Either the server operator is a stooge for Intel trying to drive up the client CPU requirements for web connectivity so that they can sell more chips, or the server operator has failed to establish a chain of trust to you in the appropriate manner, or someone really has compromised the connection with a man-in-the-middle attack. Any of these conditions are something that ought to be brought to the user's attention, not ignored. If you don't like seeing cumbersome security warnings for insecure https connections, how about not using https when what you really want is http in the first place?

<liw> Guest1482, iirc fakeroot doesn't work on all architectures, and there may be situations where it doesn't work on any, but it should certainly be used when possible <Clint> liw: it should always work the same on all the linux ones <liw> Clint, I have a vague recollection of libc making life difficult for fakeroot on... sh? hppa? but I may be utterly wrong here, and I hope I am <Clint> liw: there was a crackheaded struct change on alpha, but vorlon and i fixed that <Clint> "fixed" <liw> Clint, ok, so I'm utterly wrong, and the world is a better place for it <Clint> that's right, so stop spreading fakeroot fud <Clint> OR ELSE

I take it back, I offer a complete and utter retraction. The imputation was totally without basis in fact, and was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my comments may have caused fakeroot, or its family, and I hereby undertake not to repeat any such slander at any time in the future.

One of the reasons I tend not to blog very much is that I don't have much to say to the Planet Debian audience (the only place I know my blog is syndicated) that hasn't been said a dozen times before. But the world's best release party (the one good enough to cross an ocean for) gave me food for thought, and for once I'm inspired in the true spirit of blogging to write even if nobody cares what I have to say. Even if it has taken me until two months after the release to write it... Folks within the Debian community have been asking for years whether it's really still worthwhile for Debian to do stable releases, or if we're better off focusing on our "core competency" of testing and unstable and leaving stable releases to derivatives. For me, the answer to this question is an unqualified: yes, it's worthwhile. Of course that's the answer you'd expect from a release manager. Who would want to believe after committing as much time as the release team does that their efforts had been wasted? But the investment I've made in the etch release wasn't done without reflection; I recognize that the level of involvement required to be a release manager has come at some personal cost to me, as it does for each member of the release team, and I have made the investment anyway because I believe in Debian's philosophy, its goals, and its community. Even outside of a stable release, Debian packages really are great; in spite of the bugs and library transitions that we as release managers spend our time on in unstable and testing, and figures showing that within a month of the etch release we already had some 500 RC bugs identified for lenny, both unstable and testing do a great job of meeting the needs of many of our users. And package maintainers are constantly improving their packages in unstable, fixing bugs and adding new features. Unstable is a flowing river, vibrant and vital, never the same twice -- and only rarely are people dragged to their deaths by the undertow. ;) Maintainers often don't get to choose the version of their package that goes into stable. When it comes to a stable release, the bug you know is quite often better than the bug you don't. But although the release team is charged with chasing out the release-critical issues in preparation of a stable release, it isn't just the release team who deserves credit for etch. Etch is a monument to the work of all Debian maintainers, who have each helped shape the release with their contributions. "Stable" doesn't mean "perfect", but it does mean "lasting": in etch we have not only created what I think is the highest-quality OS I've ever had the privilege to be involved in, we have created something permanent that will be burned to thousands or millions of disks, something that users will continue to use and install for years to come. Far from standing in opposition to unstable, it is a perfect complement, letting us share everything that's great about Debian with users for whom tracking a constantly-changing testing or unstable simply isn't an option. I had decided well before etch was finished that it was time for me to move on from serving as release manager, but I still look forward to great things from Debian stable for lenny and releases beyond. With last weekend's release team meeting in Juelich, and the wonderful collaboration that's sure to take place this week at DebConf 7, I think we're off to a great start. The grumbling on IRC about broken packages and missing builds and uncoordinated library transitions is already in full swing for lenny -- and I'm no small contributor to that myself even now -- but we shouldn't let that blind us to what a great achievement etch has been for the Debian community, and what a great achievement lenny will be when it's released exactly on schedule next year.

... to translate the release notes to German. While one part still hate Frans, Vorlon and the other authors for giving us such a short time frame, a bigger part of mine would like to express his gratitude for working so hard on them. Many thanks!

Fourteen ways in which you can avoid starting a flame war on a Debian mailing list On an IRC brainstorming on what talk I should give at FOSDEM, liw suggested:

"Fourteen ways in which you can avoid starting a flame war on a Debian mailing list".

In the end I went for something more technical, but I've never stopped thinking about liw's challenge. I ended up writing talk notes about such a potential talk. Here they are. The classics

• Unsubscribe
• Killfile
• Ignore

The radicals

• Configure mail server to drop all incoming mail
• Configure mail server to drop all outgoing mail
• Pipe all incoming mail bodies through chef before delivery
• Pipe all incoming mail bodies through dadadodo before delivery
• Replace all incoming mail bodies with polygen-generated messages before delivery

The radicals, applied selectively

• Configure mail server to drop all incoming mail from people you don'tlike
• Configure mail server to drop all outgoing mail from people you don't like
• Pipe all mail from people you don't like through chef before delivery
• Pipe all mail from people you don't like through dadadodo before delivery
• Replace all incoming mail from people you don't like with polygen-generated messages before delivery

The From tricks

• Hack mutt's display to swap From names randomly
• Hack mutt's display to use polygen to replace all From names with randomly generated ones
• Hack mutt's display to replace all From names with "Vorlon"
• Hack mutt's display to hide all sender names

The naggers

• Hack mutt to disallow replying to a mail for 30 minutes after it gets read for the first time
• Hack vim to tell workrave to interrupt hard and often when you are editing mail replies

The conscience ticklers

• Reread the last 5 mails in your sent-mail folder before replying
• Google search old mails of yours before replying
• Consider what Joey Hess would think of you if he ever read your mail

The subtle

• Write in your TODO list that you definitely need to reply to that mail

The subtle, 1 week later

• Write a TODO-list application to keep track of all that mail you definitely need to reply to

Q: What do you want to be when you grow up?
A: I don't want to grow up, but if I do, I want to be vorlon.

Steve Langasek writes: … and while we don’t think we’ll be able to hit the Dec 4 deadline … It makes me feel sad. Lars will not get his tattoo: Everyone else is getting drunk, and it affects me. I make the silly bet about Debian releasing on time: if we do, I’ll get a Debian tattoo. Not to worry, I win either way.

This is the first of my two formal reports to the Dunc-Tank board on the release management funding experiment. Although submitted to the board some time earlier, I've delayed publishing it to the wider community until a release update could be sent out with more concrete information on timeline adjustments as Debian developers are wont to demand.

---

I'm supposing that I don't need to give you any more specific details on what I've been working on than what's already been posted in my blog. There has certainly been plenty to keep me busy the past three weeks, including a lot of triage work on the state of bug reports in the BTS, managing the last of the major package transitions into testing for etch, removing packages and NMUing them, and it has indeed kept me busy. Busy enough that I've been lax when it comes to talking about it, either here or in my blog. :) Has the hard work paid off? Well, http://bugs.debian.org/release-critical/ shows a sharp decline in release critical bugs affecting testing over the same time period, following the peak resulting from Dunc Bank's successful campaign of identifying latent release-critical bugs in etch. Unfortunately, we have no statistics that track the number of RC bugs closed or opened over time, which makes it hard to judge how large of a dent my own work has made in the overall bug count. It's also totally guesswork to try to judge whether Dunc-Tank has encouraged others to help with the release overall, or discouraged them from doing so. What I can say is that, even though the past month coincides both with the tail-end of the Dunc Bank mass bug filings and multiple archive-wide rebuild efforts, the bug count is moving in the right direction, and I am seeing many maintainers being responsive to bugs in their packages and a number of active NMUers. If not for the buzz-kill of Lucas Nussbaum's latest round of build failure reports :), we would be down from over 300 RC bugs to less than 200 right now, which probably represents at least twice that many RC bugs closed. In terms of how the time I'm putting into this release compares with the sarge release, I'd say it's pretty comparable. That's actually quite a positive statement about Dunc Tank's role, IMHO; getting a Debian release out is uphill all the way, and whereas the sarge release came at a time when I was in a position to work more or less full time on it without compensation, my availability this time around would have been greatly reduced, and progress would have been much more heavily dependent on individual maintainers and semi-periodic bugsquashing parties, which I'm not sure is any longer enough to offset the rate at which new RC bugs are created in the distribution by uploaders. As it stands, I do find myself trying to consciously avoid a hero complex of needing to fix every bug personally, but there are after all only so many options for getting bugs fixed for release. A lot of maintainers respond positively to gentle nudging about their RC bugs, but there are still bugs that the maintainers can't or don't fix and that no NMUers take on, which does leave it more or less up to the release managers to address -- which is why one of my tasks for this week is to try get the count of RC bugs over 20 days old down from 90 to around 20-30, as these are the bugs that really do need more attention to get them resolved. So yes, Dunc-Tank is making a positive difference. Andi and I have reviewed the status, and while we don't think we'll be able to hit the Dec 4 deadline (even if we get the bug count down immediately we're waiting on the debian-installer to release, which needs at least one more release candidate with the 2.6.18 kernel), we do believe that a release before the end of the year is very possible and I'm looking forward to starting the full freeze in the next few weeks.

While NMUing plays an important part in getting us to a release, as shown by the thousand or so fixed-in-NMU RC bugs that we recently cleaned up the BTS state on, it's evident after doing this whole release-managing thing for a while that there is a very high (non-linear) correlation between the age of an open RC bug and the likelihood that a release manager is going to have to touch it at some point in order to get it fixed. By and large, maintainers really do a good job of fixing their own packages, which is probably something we don't say enough - maybe 75% of all RC bugs, I'd guess, will (or would) get fixed by maintainers in the first week without anyone needing to poke them about it, and of the remainder, probably another 80-90% get taken care of by BSPers and serial-NMUers like bug-a-day mascot Steinar Gunderson. That's why I'm not bothered overly much by the idea of full-archive searches for hidden RC bugs, like Lucas's piuparts tests, affecting the release timeline, because I know that 95-98% of those bugs are going to be gone two weeks after they're filed anyway, especially when they're no-brainer fixes to maintainer scripts or dependencies. But then that leaves the other 2-5%, which are the ones nobody else has fixed. And why hasn't anyone fixed them? Because they're the hard ones, of course... So although I follow the debian-bugs-rc list and occasionally swat a few non-bugs closed to save the maintainers time, and also provide some nudges when it looks like a package is causing RC bugs to be filed on other packages, my goal for the last full week of my Dunc-Tank contract was to get the count of etch RC bugs unfixed in unstable that are 20 days old or older down from around 50 to under 30. This seemed a reasonable goal, since it had been at 80 the week before, and it would go a long way towards helping the real blockers on the release. Initially I was aiming to bring down the count of RC bugs unfixed in testing that are 20 days old or older to this number, but quickly realized that this wasn't going to be realistic because it depended too much on the autobuilders all operating optimally and there wasn't time to both help fix 20 of the hardest RC bugs and handhold 60 RC bugfixes into testing in one week. In the end, we did miss this lesser target by a day or two. Still not a bad week's work, given that I'm pretty sure I fixed about 20 of these bugs myself in that time period (through NMUs, removals, and analysis+downgrades) and they seem to average 3 hours of work for a fix. And we've been holding at or below 30 on this list of bugs since then, so we're successfully keeping up with new bugs aging past the 20-day mark, which is also a good sign. Unfortunately, I seem to have left myself to fix the alpha Xorg 7.1 bugs on my own time. :) By now the announcement has made the rounds that the release team doesn't think we can hit the Dec. 4 target date because more time is needed for a final release candidate of the installer. Does that mean that RC bugs were the wrong thing to be focusing on for the past weeks? Well, no; if you want one place in Debian where Brooks' Law holds, I think you'll find that getting a d-i release out is it, and we still have a hard road ahead to make sure we do get our other RC issues sorted out in the same time frame. The installer just happens to put a lower limit on a release date, we still have an opportunity to screw it up from there. ;) At least the statistics suggest that we're going in the right direction.

• bugs 20 days old or older unfixed in unstable: 28
• bugs 20 days old or older, including those fixed in unstable: 52
• bugs 10 days old or older unfixed in unstable: 40
• bugs 10 days old or older, including those fixed in unstable: 78
• all RC bugs in unstable: 138
• all RC bugs, including those fixed in unstable: 217

Only 13% of RC bugs fall into the "20 days or older and unfixed" category. Half of all RC bugs over 10 days old have a fix of some kind in unstable, and 64% of all reported RC bugs are less than 10 days old. We'll see whether this graph backs me up on this in a couple more days.

According to turmzimmer, there are 53 RC bugs remaining in testing that are not fixed in unstable and are over 20 days old. This is great, because that number is down from about 80 a week or so ago; but that leaves a good number of harder bugs open that could probably use some attention from NMUers given that these are the bugs that are specifically not seeing turnaround from maintainers. Just think, if every developer fixed just one of these bugs, we would have 19 NMUs for each package, the ftp team would be pissed, and we could release just two weeks from now once ftp-master.d.o was able to clear the backlog! And remember, any bug not found in a standard 52-bug deck is a spare portabella mushroom.

As a matter of principle, I try to avoid any conflict of interest between my release manager and alpha porter hats, by e.g. deferring to my co-RM when there's a question of whether a particular compromise should be made to benefit alpha's releasability. Where Dunc Tank is concerned, that means some changes in priorities for bugs to work on, since I'm being paid to try to get etch out in a timely manner, not to keep the alpha port afloat. OTOH, alpha is not the only arch that produces RC bugs needing release team attention, and Dunc Tank only dictates how I spend 40-50 hours of my week -- which means another 20-30 hours a week of Debian work that I can set my own priorities for, right? So the theme ingredient over the weekend was: problems on the alpha port.

• NMUed qdbm with a workaround for the long-standing build failure, helpfully filed by Aur lien G r me as bug #394626; this in theory makes it possible to get the fix for bug #367374 into testing by the normal route, but now hyperestraier and qdbm both have a very strange build failure on alpha and mips...
• It took quite a bit of time to track down RC bug #378346 in gail, what with all the libraries that needed to be rebuilt from experimental. Turns out to be a garbage collection issue fixed upstream. Who knows why this only showed up on alpha?
• I also poked a bit at the kernel for alpha, for the possibility of supporting installation on TITAN and TSUNAMI class systems. It looks promising to have this in for etch, which would be nice because these are higher-end alphas that could extend the lifetime of the alpha port overall if we can manage to turn that support into something like a new porter machine...
• Then I spent some more time poking at the kernel thanks to 397139, which showed that the fixes to get the kernel building under gcc-4.1 on alpha didn't quite do the trick.

I'll give myself 4/5 points for presentation, 5/5 points for use of the theme ingredient, and 6/10 points for taste (this plastic computer case needs more salt). And of course, waiting for Debian kernel packages to compile on an LX164 alpha gives one time to do other things too, like following through on the RC bugs that the BTS has wrong version-tracking information for, and preparing an NMU here and there. Less than 200 RC bugs left now, and dropping daily!

2.6.18-4 was uploaded on Sunday and should be soonest available after dinstall run for most archs. The ia64 build failure is fixed in svn thanks to Thiemo Seufer (ths). alpha is waiting for an updated gcc (see patch in #397139). s390 is currently broken by vserver, patch is awaited soon. linux-latest will be updated tomorrow and expect soon a 2.6.18-5, once those issues are cleared.
linux-image-2.6.18-2- is the Debian kernel team stabilized kernel. Please install it and report eventual bugs. If you know a patch from Linus git tree that fixes your problem even better name it. Thanks for your testing!
We had been quite busy to feed stable with patches that fit the Documentation/stable_kernel_rules.txt. Goodies like Xen, drm-i965 or ahci backport are shared with Fedora Core 6 release. Beyond that for example the r8169 patch series or ccisss support for 2 TB volumes got backported. Out of reach are destabilizing patches like the new 2.6.19 ACPI patches. Further backports are planed for the SUSE reiserfs 2.6.19 patches and vorlon has a fix in the pipe for the vga console driver on alpha.

History
For the sarge release official kernel-images from the newly formed Debian kernel team came together with initrd-tools. initrd-tools Maintainer was jbailey. It saw some care from tbm, vorlon and me before the actual release. Remembering the flow of bugs and installation-reports it accounted for a huge number of install failures plus lacked many features the Red Hat mkinitrd had. Ubuntu got hit more directly as hoary released with a newer kernel than 2.6.8 and due to the initrd-tools devfs requirement.
initramfs-tools originated out of the need of a direct replacement. Inspired by an initramfs OLS talk jbailey had the goals of boot-time hardware detection using the nice and neat features the Linux 2.5 branch incorporated: The sysfs support of the Linux drivers allows an neat userspace daemon aka udev to coldplug them. udev is the replacement of a maze of slow shell scripts called hotplug package. The second big feature is the new initramfs format (the curious may want to read Documentation/filesystems/ramfs-rootfs-initramfs.txt of any current linux-2.6 source). For a boot loader initramfs or initrd is the same fish. The smaller and more efficient in kernel code makes the difference. The initramfs gets loaded much earlier, due to being only an cpio archive and not an fs allowing it to completely rule the rootfs search and mount. One initial assigned spec had the name "easy NFS root". The LTSP guys joined in and showed interest in incorporating their work.
Technology
initramfs-tools got default in Debian together when the first common linux-2.6 (2.6.15) package reached etch, powered all the Ubuntu releases from Breezy on and is used by the grml live-cd. Since archive inclusion almost a year ago it got much better support of all the various linux boot parameters (see man initramfs-tools or the "official" Documentation/kernel-parameters.txt), keeps an backup initrd around and has better block-based bootloader support (lilo, ..). klibc has been ported to _all_ the Debian release archs where it is in use and compiles fine on m68k and sh.
The initramfs-tools early userspace is very flexible based on it's hooks for initramfs build and boot. Thanks to alphix for the help on shaping the building blocks. There are initramfs hooks in cryptsetup, evms, dmraid, firmware-qlogic, lvm2 multipath, mdadm, usplash, .. Reviewers, uploaders and sponsors included fs, jbailey and Sesse. Most of the time it is sufficient and easy to test changes in qemu images (See slides workshop early userspace). The best wish of an early userspace is not to be remarked - aka happy booting. Nevertheless thanks a lot for the public support: Achieving Xen Disk encryption support in Etch, Popping my initramfs cherry, ..
Future
The latest initramfs-tools release seems almost ready for the upcoming etch release. The bug reports coming over from installation-reports are happily rare. Although the uuid based fstab generation solution is not yet integrated in the debian-installer. There are one or two known nitpicks left-over in the bts plus one bugger: udevsettle may exit to early, when not all the discs are ready for use. For grub there is a fail-over net, but which does not account for a to early md or lvm2 boot hook. Future initramfs-tools development will focus on an optional small klibc based Modules=dep hand walking /sys initramfs generation allowing better embedded support. grub2 will present run-time assembly challenges for the initramfs.